A storing device such as a Hard Disk Drive (HDD) sometimes has, at a low possibility however, errors in writing data into the storing device in response to a write command from a host device. Examples of the errors are a wrong address that the data is written into a different address from an address instructed by the command and lost write that data is not written into the instructed address. A wrong address is caused when head seek in the HDD has failed or the like; and lost write is caused when data writing has been carried out in a state where the HDD head comes apart from the disk to lower the magnetic force therebetween.
As described above, causes of a wrong address and lost write (hereinafter also collectively referred to as a “writing error”) in an HDD frequently depend on the state of the HDD. This makes a controller that controls accesses to the HDD difficult to detect a writing error that occurs after the controller instructs data writing into the HDD in response to a write command. Consequently, the controller sometimes has difficulty in notifying occurrence of a writing error to the host device.
One of the known methods to detect above writing errors uses, for example, a Block Check Code (BCC). A BCC is data used for detecting an error in data by means of Cyclic Redundancy Check (CRC). A BCC includes the result of CRC that the controller has performed on the data directed by a write command and information of the write address directed by the write command.
For example, in response to a read command from the host device, the controller compares the read address directed by the read command with address data included in the BCC of the block read from the HDD. In cases where the compared two addresses do not match, the controller detects that the block read from the HDD has been written therein data of a wrong address, which means that the read data is data that has have to be written into another address.
However, simply using a BCC sometimes makes the controller difficult to detect that the data directed by the read command is written into a different address from the read address or has lost write. One of the above cases is that although data in the block directed by the read address is old data supposed to be overwritten with different (new) data, there is high possibility that address in the BCC in the same block is the correct read address and therefore the result of comparing the read addresses match.
In one of the related techniques known to public, the controller generates chronological data, such as a counter value, that makes it possible to discriminate the current write command from the latest write command into the same storing region (see, for example, Patent Document 1). In this technique, the controller provides the generated chronological data to each of updating data and parity data, writes the updating data and the parity data into different disks, compares the chronological data provided to the updating data with that provided to the parity data when reading data in response to the current write command, so that a possible writing error can be detected.
In another known related technique, the controller sets a history block that stores therein an updating state value such as the updated generation number for each block, and regards each history block as a management unit to be inspected (see, for example, Patent Document 2). In this technique, the controller calculates the updating state value for each management unit, stores the updating state value into a memory, and writes the entire management unit including the updating data and the updating state value into the disk. After that, the controller compares the updating state value read from the disk with the updating state value stored in the memory to detect lost write on the disk.
As the above, there have been provided known techniques that the controller compares the counter value (updated generation number) stored in the disk with the counter value for comparing stored in a different disk or a memory and, when the counter values do not match, detects the occurrence of a writing error. These techniques are capable of detecting a wrong address that the data is written into a different address from an address instructed by the read command and lost write that data is not written into the instructed address.
[Patent Document 1] Japanese Laid-open Patent Publication No. 2010-182087
[Patent Document 2] Japanese Laid-open Patent Publication No. 2006-252530
[Patent Document 3] Japanese Laid-open Patent Publication No. 2007-122476
In the above technique, the chronological data and the updating state value, which are stored into the storing region of the HDD, may suppress the available disk volume, that is the disk volume that can store the business data (user data), depending on the data size of the chronological data and the updating state value. In particular, the technique that generates chronological data and writes such chronological data corresponding to each block largely suppresses the available disk volume in accordance with an increase in data size of chronological data.
A solution to the above minimizes the chronological data and the updating state value to reserve an available disk volume. Here, the chronological data and the updating state value are assumed to be a counter value. An example of a counter value is represented by an n-bit value (where n is an integer equal to or more than one) and is in the range of 0 to m (where m=2n−1). In this solution, the counter small in size may have difficulty in detecting a wrong address and lost write as to be detailed below. The following description focuses on the occurrence of lost write, but the same description is applied to the occurrence of a wrong address.
FIG. 6 is a diagram denoting the lost-write detectability of the controller when the counter value is a two-bit data (n=2). In the example of FIG. 6 assumes that under a state where the value “D0” is set in the predetermined block having a counter value of “0” representing the initial state, write commands to each write values “D1”, “D2”, “D3”, and “D4” are successively issued but all results in the occurrence of lost write.
As denoted in FIG. 6, even when lost write has occurred successive three times (“D1”-“D3”), the controller is capable of detecting the lost write by comparing the counter value of the predetermined block stored in the disk with the counter value for comparing.
However, in cases where lost write has occurred successive four times (“D1”-“D4”), the counter value for comparing overflows and the counter value for comparing is cleared (returns from three to the initial value zero), and the counter value for comparing comes to be the same as the counter value of the predetermined block. At that time, the controller determines the both counter values match and therefore does not determine that lost write has occurred. Having a smaller maximum value of the counter value, a counter having a smaller counter size has higher possibility that the counter value is the same as the counter value for comparing.
As the above, when a counter used for writing error inspection (writing inspection) is made to have a small size to reserve an available disk volume of the storing device, the controller sometimes has difficulty in detecting a writing error, which lowers the reliability of the writing inspection.